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REMARKS/ARGUMENTS 

Claim Rejections - 35 U.S.C. § 112 

Claims 4-5 are rejected because there is insufficient antecedent basis for the Umitation 
"the network entities carrying the service". 

Claim 4 has been cancelled. 

Applicant notes that a group of alarms associated with a network entity may include 
alarms in common with another group of alarms associated with another network entity. Claim 
5 adds a step of associating an alarm with at least two relevant network elements. 

Claim 5 depends on claim 1. The "subset of alarms" in claim 1 is associated with a 
service. The step of grouping in claim 1 divides the alarms into a number of groups of alarms, 
where each group of alarms is associated with a network entity. The term "carrying the 
service" in claim 5 is superfluous. The Umitation of claim 5 has been amended to read: 

"wherein the step of grouping further comprises a step of associating at least one alarm 
in the subset of alarms with at least two network entities from among said number of network 
entities . 

Claim Rejections - 35 U.S.C. § 102 

Claims 1-13 are rejected under 35 U.S.C. § 102(e) as being anticipated by Valadarsky 
(U.S. Patent Pubhcation 2002/01 1 1755). 

The present application discloses a service-based problem identification and correction 
in a network. Valadarsky discloses a topology-based system for topologically analyzing alarms 
in a network. 
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Applicant notes that a network typically provides a large number of services where a 
service uses a number of network entities. Failure of a network entity may affect numerous 
services. A system devised for topology-based problem identification determines root causes 
of problems based on topological relationships among network entities. A system devised for 
service-based problem identification relates alarms to a specific service and is of interest to a 
service provider. 

Before discussing the individual claims, it is useful to compare the present appUcation 

and the Valadarsky reference. 

Definition of the term "service" in the present application 

The term "service" as used in the present appUcation refers to a connection identified by 
an originating node, a destination node, and other attributes such as a wavelength channel. The 
following passages further emphasize the service-oriented aspect of the present application. 

The abstract of the present appUcation states: A method for describing problems in a 
telecommunications network is provided, wherein the alarms for a network service displayed 
on an operator's console are presented in the order of the path comprising the service and 
associated with respective network elements, foUowed by a description of a recommended 
corrective procedure for the alarms. 

The need for service-based problem identification is explained in paragraph 

[0003]: 

[0003] As the complexity of telecommunications networks continues to grow, the level of 
required reUability and availability of the networks continues to rise correspondingly. These 
factors place an increasing burden on diagnostic systems that are used to isolate and correct 
network problems. For network service providers , quick and accurate problem diagnosis and 
correction is critically important. 

An exemplary "service" is described in paragraph [0005]: 
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[0005] A common objective of the optical network is to carry traffic in the form of optically 
encoded binary data. A service, in this context, can be defined as the ability to carry this 
traffic from one point to another in the optical network . The optical network generally 
supports more than one service. 

A service-based method for describing a problem in a network is outlined in 
paragraphs [0043] and [0044]: 

[0043] A method for describing one or more problems for a service in a telecommunications 
network described above and according to a first embodiment of the invention is illustrated in 
FIG. 1 by flowchart 10. 

[0044] At the start (box 12), information is provided on the service, including the service 
identifier and corresponding channel identifier, a WDM wavelength identifier, which can be 
in the form of an ITU Grid number, an identifier for a node at the start of the service, 

identifiers for the path endpoints of the links forming the path, identifiers for intermediate 
network entities, and an identifier for a node at the end of the service (box 14). For example, 
this information could be provided at a network management Server (NMS). Also, a subset of 
alarms is selected by examining the network entities carrying the path, and selecting the 
network entities with an alarm (box 14). Next, an ordered hst of alarms is generated for the 
network entities carrying the service (box 16). The ordered hst of alarms is generated in 
order of the direction of the path of the service, starting at the beginning of the path, 
progressing thi-ough alarms for path links and network entities comprising the path, and 
finishing at the end of the path. The ordered list of alarms is then transformed into one or more 
problem descriptions for the service (box 18). Next, the ordered list of alarms is transformed 
into a description of a corrective procedure for the problems (box 20), and the process is 
complete (box 22). 

A step of generating an ordered list of alarms along a path of a service is stated in 
paragraph [0045]: 
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[0045] Flowchart 16 shown in FIG. 2 illustrates the step 14 of FIG. 1 of generating an ordered 
list of alarms in the method of FIG. 1 in-more detail. At the start (box 22), the first path link at 
the beginning of the path that comprises the service is selected (box 26). 

A service-based corrective procedure is stated m paragraph [0054]: 

[0054] Thus, a method for the description of one or more problems for a service in a 
telecommunications network and a corrective procedure is provided. This method may be 
used where a list of network entities for a service is provided, for example, at an NMS. 

Definition of the term "service" in the Valadarsky reference 

The term "service" in Valadarsky refers to a function or a component of a Topology- 
based Reasoning System (TRS), as described in paragraph [0261], and subsequent paragraphs 
recited below: 

[0261] The service preferably includes the following main building blocks: 

(Applicant notes that a building block is part of a software system, and a "service", as used in 
the Valadarsky reference, comprises a number of building blocks. A service in the present 
application is a connection identified by an originating network entity, a destination network 
entity, and other attributes such as a wavelength channel and a modulating dither tone.) 

[0262] A. Correlation Engine-This part of the CorrelateService preferably deal with the 
following actions: 

[0271] Recovery—Read the alarm repository after the CorrelateService has been initialized (for 
example, after a "crash"). 

[0277] The CorrelateService preferably gets alarm information (new alarms, updates of alarms 
and drop of alarms) from the N_netcorre_handler, and processes them. 

[0279] 1) The Service receives a new alarm, update of alarm data or drop of an alarm. 
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(Applicant notes that a Service in Valadarsky comprises software components capable of 
receiving and processing alarms. A service in the present appUcation is a connection along a 
path as described above.) 

[0282] 4) The decision algorithm computes the correlation on a group. Before terminating, it 
activates an action in the CorrelateService. The decision algorithm preferably works on several 
separate threads according to a pre- setup of the system. 

[0283] 5) The CorrelateService calls a method for the creation of a derived alarm (if needed), 
and sends the parent/child data of the group to the N_netcorre handler, that is "subscribed" to 
the data. 

[0295] Recovery after the CorrelateService was re-run. 

[0385] The CorrelateService preferably create an alarm, with the following field values. 

Service-based system versus Topology-based System 

The abstract of the present appUcation states: "... the alarms for a network service 
displayed on an operator's console are presented in the order of the path comprising the service 
and associated with respective network elements, . . .". 

The title of Valadarsky' s application is 'Topology-based reasoning apparatus for root- 
cause analysis of network faults", and the abstract states: 

"... the system includes a topology-based reasoning system (TRS) operative to 
topologically analyze alarms 

The following excerpts from the Valadarsky reference outline the topology-based system 

{emphasis added)'. 

[0006] There is thus provided in accordance with a preferred embodiment of the present 
invention a fault management system having one, some or aU of the following features: 

[0007] Correlator-i-TRS is based on fault propagation rules and topological network 
information . 
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[0008] The topology is translated to a graph onto which the incoming alarms and expected 

alarm behavior are coordinated. This graph is scanned in real time in order to find the right 
root-cause . The graph is used rather than a matrix, in order to handle large networks. 

[0021] TRS uses graph traverse in order to find the root cause and in order to find all the 

alarms that belong to a root cause. 

[0023] TRS uses topologic distance between the alarms in order to make the groups. 

[0033] Correlator+ TRS interworks with Correlator+ ES (which is an expert system based 
correlation product). Correlator+ may comprise two modules, one using a topology-based 
reasoning approach , and the other using a classic expert system approach , to ensure the widest 
fault coverage possible. (Some network faults are best handled by the fii-st approach and others 
by the second approach). TRS fulfills the topology-based reasoning role and a second module, 
ES, fulfills the classic expert system role. The former (TRS), as indicated above, uses a 
topology-based reasoning approach . The later (ES) is built on classic expert system technology. 
When both are installed together, they interwork as one integrated system. 
[0037] Also provided, ... , is a root cause analysis system operative in conjunction with fault 
management apparatus, the system including a topology- based reasoning system (TRS) 
operative to topologically analyze alarms in order to identify at least one root cause thereof. 
[0042] Additionally in accordance with a preferred embodiment of the present invention, the 
TRS is operative to represent the topology of a network being analyzed for faults as a graph. 
[0067] Further in accordance with a preferred embodiment of the present invention, the TRS is 
operative to cluster incoming alarms into groups based at least partly on the topological 
distance between the alarms. 

[0096] Correlation—Involves interpreting state changes, which occur in networks, network 
elements, and operational equipment or systems, in the Ught of related conditions and 

circumstances. 

[0134] Alarm correlation— Identify alarms that may be correlated without obtaining data from 
external sources. In parallel to that buUd groups of alarms to apply topological correlation . 
Perform the rough and fine reasoning algorithms. 
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[0147] 5. The alarms are grouped according to time characteristics and clustered by using 
network topology considerations . 

[0148] 6. Each cluster is investigated by the correlation engine that deducts the probable root 
cause or root causes for that group. 

[0226] The correlation system needs to query preferred external sources in order to do 
advanced correlation. This means mainly to get configuration ad topology information but also 
for example to determine if the alarms are service affecting or not. The nature of this process is 
real-time and near real-time. 

(Applicant notes that, in Valadarsky, alarms are classified as service affecting or otherwise. 
However, an alarm is not associated with any of the services it affects; the affected services are 
not identified collectively or individually.) 

[0280] 2) The grouping functions are called to assign the alarm to dynamic groups. The alarms 
in each group are then clustered according to the network topology . 

Discussion of the Claims 

In reference to claim 1, the Examiner asserts that Valadarsky teaches the Umitation: 

"selecting a subset of alarms associated with a service, said service having a unique 
identifier and being carried by a path in the network, the subset of alarms being selected from a 
list of alarms in the network". 

The Examiner refers to paragraphs [0145] and [0355] in Valadarsky, recited below: 

[0145] When an event occurs and identified as an alarm, that alarm is given an ID, which 
uniquely identifies the alarming object in the configuration database. 

[0355] According to the fault propagation mles. the algorithm deducts the fault propagation 
step by step. In the example of FIG. 7, the algorithm deducts that a problem may have occurred 
in cable 1, since a fault in the cable may generate alarms in both ports, and those alarms in the 
ports may generate alarms in the network elements. 

Applicant submits that neither of the above two paragraphs discloses a step of 
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associating an alarm with a service. 

The Examiner further asserts that Valadarsky teaches the hmitation: 

"grouping alarms in the subset of alarms associated with said service in a number of 
groups of alarms, each group of alarms being associated with said service and with a network 
entity". 

The Examiner refers to paragraphs [0134] and [0335] in Valadarsky: 

[0134] Alarm correlation—Identify alarms that may be correlated without obtaining data from 
external sources. In parallel to that build groups of alarms to apply topological correlation . 
Perform the rough and fine reasoning algorithms. 

[0335] A group of alarms that have arrived during the same time interval, are clustered into 
groups according to the correlation rules and network topology . A group contains alarms that 
have any connection between them according to the graph . The clustering function searches for 
connections on the graph between the alarms in the group. Two alarms are defined as 
" connected " if they have a mutual root cause . All the alarms from the group that have the same 
root cause preferably are grouped to the same cluster. 

Paragraph [0 1 34] l efers to a process of topological correlation. Valadarsky defines the 

term "correlation" in paragraph [0096]: 

[0096] Correlation— Involves interpreting state changes, which occur in networks, network 
elements, and operational equipment or systems, in the hght of related conditions and 
circumstances . 

Paragraph [0335] describes a process of grouping based on network topology and 
relying on a graph. A group in Valadarsky contains alarms that have a common root cause 
while a group in the present application comprises alarms associated with a service . 

The Examiner further states that Valadarsky discloses the step of: 
"arranging the groups of alarms according to a sequence in which they appear in a 
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traversal of the path of the service in the network". 

The Examiner refers to paragraphs [0366] -[0369] in Valadarsky: 

[0366] The backward and the forward traverses are preferably done using the following 

principle: 

[0367] Given a Node ("node 1") on the graph that represents an object on the network, and a 
probable cause on that object the algorithm finds all the elements ("node 2") that are (1) 
connected to this Node by one of the relations described above and~(2) there is a rule that 
relates to the probable cause on the first node. These elements are inserted into a queue along 
with the probable cause that is deducted by the rule, and in time preferably is used as the first 
node and probable cause pair. 

[0368] In the "backward traverse" the "node 2" is a suspect probable cause for the original 
alarm. In the "forward traverse" it is a theoretical expected alarm for the original root cause. 

[0369] The traverse sequence is finished when there is nowhere to go from the end nodes, or 
the traverse has reached a hmit distance between the original alarm and the probable root cause 
(in the "backward fraverse") or the original root cause and the alarm (in the forward traverse). 

Applicant submits that paragraphs [0366] to [0369] describe a process of the topology- 
based reasoning system (TRS) which uses a graph to identify related network elements and find 
a relevant rule. A "rule" is defined in paragraph [01 10] in Valadarsky: 

"[0110] Rule—Description of the behavior of alarms when particular type of fault occurs". 

There is no mention anywhere in Valadarsky of a process of arranging alarms 
according to a sequence in which they appear along a path of a service. 

The Examiner further states that Valadarsky discloses the step of: 
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"transforming each alarm in each group of alarms into a problem description for the 
service". 

The Examiner refers to paragraphs [0160]-[0162] and [0382-384] in Valadarsky, recited 

below: 

[0160] The output of the decision algorithm includes: 

[0161] 1. The correlation results, the root causes and their confidence, correlation identifiers 
etc. 

[0162] 2. Table of the parent/child and derived status of each alarm that was processed by the 
correlation mechanism. 

[0382] The correlation results may be preferably displayed in two forms: informative 

description and recommendation. The decision whether or not to display the results as a 
recommendation preferably is based on the confidence of the root cause. 

[0383] Preferred Definition of a Derived Alarm 

[0384] A derived alarm is preferably a fictive alarm, raised by the system to report a fault in a 
network element that is incapable of reporting alarms by it self (such as a cut cable). The 
correlation decision mechanism may suggest a fault in a network entity, which is defined by 
object type and object ID identifiers. The mechanism may also output the alarm type and 
probable cause of the fault. 

Applicant submits that none of the above referenced paragraphs discloses a step of 
providing a problem description for a service. Valadarsky is silent regarding associating alarms 
with a service as claimed in the present apphcation. 

Thus, Valadarsky does not disclose any of the four limitations of Claim 1. Accordingly, 
it is respectfully requested that the rejection of claim 1 be withdrawn. 

In reference to claim 2, the Examiner states that Valadarsky teaches a method of claim 
1 further comprising the step of providing a corrective procedure. The Examiner refers to 
paragraph [0105]. 
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Applicant submits that the purpose of finding a root-cause of a problem is to facilitate a 
solution. Paragraph [0105] in Valadarsky defines the term "root-cause" as a cause which is 
sufficiently detailed to enable repair. 

Valadarsky determines a root-cause which enables repair in a topology-based reasoning 
system (TRS) while Claim 2 of the present apphcation adds a step of providing a corrective 
procedure for a specific service according to the service-based method of claim 1 which 
associates alarms with a service. 

In reference to claim 3, the Examiner states that Valadarsky teaches the method of 
claim 1 wherein said grouping further associates each group of alarms with a type of said 
network entity. The Examiner refers to paragraph [0355]. 

Applicant notes that Claim 3 of the present application refers to selected network 
entities carrying a specific service while Valadarsky identifies a network component (Cable 1 - 
paragraph [0355]) resulting in alarms without associating the network component with a 
specific service. 

Accordingly, it is respectfully requested that the rejection of claim 3 be withdrawn. 

In reference to claim 5, the Examiner states that Valadarsky teaches the method of 
claim 1 wherein the step of grouping comprises associating at least one alarm with at least two 
network entities. The Examiner refers to paragraphs [0134] and [0335] in Valadarsky: 

[0134] Alarm correlation— Identify alarms that may be correlated without obtaining data from 
external sources. In parallel to that build groups of alarms to apply topological correlation . 
Perform the rough and fine reasoning algorithms. 

[0335] A group of alarms that have arrived during the same time interval, are clustered into 
groups according to the correlation rules and network topology . . . 

Applicant notes that claim 5 associates an alarm with more than one network entity. 
Paragraphs [0134] and [0335] relate alarms to network topology but do not disclose or 
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contemplate a step of associating an alarm with two or more network entities. 

Accordingly, it is respectfully requested that the rejection of claim 5 be withdrawn. 

In reference to claim 6, the Examiner states that Valadarsky teaches a method for 
describing a problem in a network comprising a number of network entities, the method 
comprising the &st four limitations of claim 6. 

The first four hmitations of claim 6 have been discussed above in reference to claim 1 
and clearly distinguished from the referenced prior art. 

The Examiner further asserts that Valadarsky discloses the hmitation: 

"wherein the step of transforining each alarm further comprises the step of forming at 
least one template including text substitution markers". The Examiner refers to paragraphs 
[0383] to [0406] in Valadarsky. 

Applicant notes the above limitation applies to the step of transforming each alarm into 
a problem description for a service and adds a further step of forming templates , where a 
template includes text substitution markers . Templates with markers are illustrated in 
FIG.3a-FIG.3d and FIG. 8 of the present apphcation. The templates are clearly devised for 
service-based problem description. Please see reference numerals 42, 48, and 54, and 
paragraph [0047] of the present apphcation: 

[0047] . . . The service identifier that is provided (box 14 of FIG. 1) is substituted at the 
position of the first text substitution marker 42 . 

Paragraphs [0383] to [0406] in Valadarsky describe a "derived alarm", defined in the 

Glossary section, paragraph [0106] as an "alarm created by management system based on 
received data that better describes root-cause than any alarm received from network (such as a 
cut wire)". 
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The "derived alarm" described paragraphs [0383] to [0406] is not associated with a 
respective service. 

Accordingly, Valadarsky does not disclose any of the five limitations of claim 6 and it 
is respectfiilly requested that the rejection of claim 6 be withdrawn. 

In reference to claim 7, the Examiner states that Valadarsky teaches the method of 
claim 6 wherein the text substitution markers correspond to network entities. The Examiner 
refers to paragraphs [0383] to [0406]. 

The text substitution markers of claim 7 relate to problem description for a service. As 
discussed above, Valadarsky is silent regarding associating alarms with respective services. 

Accordingly, it is respectfully requested that the rejection of claim 7 be withdrawn. 

In reference to claim 8, the Examiner states that Valadarsky teaches the method of 
claim 6 wherein the path is a two way path and the step of arranging the groups of alarms 
comprises arranging the groups of alarms in the direction of the path from the beginning of the 
path to the end of the path. The Examiner refers to paragraphs [0366] to [0369]. 

Applicant submits that the referenced paragraphs describe a forward traverse and a 
backward fraverse of a graph representing a network in order to find a root cause of a problem. 
There is no mention anywhere in Valadarsky of relating an alarm to a path of a service. 

Accordingly, for the reason that Valadarsky does not disclose the hmitation of 
"arranging the groups of alarms in a direction of the path from a beginning of the path to an end 
of the path", it is respectfully requested that the rejection of claim 8 be withdrawn. 

In reference to claim 9, the Examiner states that Valadarsky teaches the method of 

claim 6 wherein the path is a two way path and the step of arranging the groups of alarms 
comprises arranging the groups of alarms in a direction of the path from an end of the path to 
the beginning of the path. The Examiner refers to paragraphs [0366] to [0369]. 
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As described in reference to claim 8, the referenced paragraphs describe using a graph 
to find a root cause of a problem. Valadarsky does not disclose relating an alarm to a service 
having a unique identifier and being carried by a path in the network as stated in claim 6 on 
which claim 9 directly depends 

Accordingly, it is respectfully requested that the rejection of claim 9 be withdrawn. 

In reference to claim 10, the Examiner states that Valadarsky teaches a method for 
describing a problem in a network comprising a number of network entities, the method 
comprising the first four limitations of claim 10. 

The first four Umitations of claim 10 have been clearly distinguished from the 
referenced prior art in the discussion of claim 1. 

The Examiner further asserts that Valadarsky discloses the Umitation: 

"wherein the type of problem comprises one or more of: a missing channel 
identification alarm; an unexpected channel identification alarm; a loss of signal alarm; and a 
channel power out of range alarm". The Examiner refers to paragraph [0384] in Valadarsky: 

[0384] A derived alarm is preferably a fictive alarm, raised by the system to report a fault in a 
network element that is incapable of reporting alarms by it self (such as a cut cable). The 
correlation decision mechanism may suggest a fault in a network entity, which is defined by 
object type and object ID identifiers. The mechanism may also output the alarm type and 
probable cause of the fault. 

Applicant submits that paragraph [0384] describes a "derived alarm" which is defined 
in paragraph [0106] in Valadarsky: 

[0106] Derived alarm— Alarm created by management system based on received data that better 
describes root-cause than any alarm received from network (such as a cut wire). 

Applicant further submits that none of the following four types is mentioned anywhere 
in Valadarsky: 

a missing channel identification alarm; 
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an unexpected channel identification alarm; 

a loss of signal alarm; and 

a channel power out of range alarm. 

Thus, Valadarsky does not disclose any of the hmitations of claim 10. Accordingly, it is 
respectfiilly requested that the rejection of claim 10 be withdrawn. 

In reference to claim 11, the Examiner states that Valadarsky teaches the method of 
claim 1 wherein the description is a verbal description. 

In reference to claim 12, the Examiner states that Valadarsky teaches the method of 
claim 1 1 wherein the description is a text description. 

In reference to claim 13, the Examiner states that Valadarsky teaches the method of 
claim 1 wherein the description is a pictorial description. 

In rejecting claims 11, 12, and 13, the Examiner refers to paragraphs [0484] to [0492]. 
Paragraphs [0484] to [0492] are recited below for ease of reference: 

[0484] In order to ease the rules definition, the defined rales may concentrate on two entities 

related to one another, by a relationship. For example: 

[0485] 1. "contains" 

[0486] 2. "connected" 

[0487] 3. "terminated by" 

[0488] 4. "In route" 

[0489] 5. "pass through" 

[0490] 6. "used by" 

[0491] The following table illustrates an example of a set of rules that can be defined: 
5 Object Fault Object Fault Type 1 Type 1 Type 2 Type 2 Relation Network Fault Card Fault 
Contains element Card Fault Port Fault Contains Port Fault 1 Fiber Fault Connected Cable 
Fault Fiber Fault Contains Port Fault Port Fault 2 Connected 

[0492] A rule is defined as a pair of object type and object ID connected by a relation. 
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Applicant submits that Valadarsky is silent regarding the form of presenting a 
description. The referenced paragraphs define six relationships for a pair of entities to be used 
in rule definition. 

Applicant notes, however, that the use of vocal, text, or pictorial presentation is a 
common practice. Claims 11, 12, and 13 depend, directly or indirectly, on claim 1 which 
comprises four steps each of which distinguishes the claimed method from the method of 
Valadarsky. Claims 11, 12, and 13 add usefiil features to the method of claim 1. 

Accordingly, it is respectfiilly requested that the rejection of claims 11, 12, and 13 be 



Claims 1 -3 and 5- 1 3 are pending. Claim 4 has been cancelled. The claims have been 
clearly distinguished from the cited prior art. 

No new material has been added to the claims. 

Favorable consideration and allowance are earnestly soUcited. 



withdrawn. 



CONCLUSION 



Respectfully submitted, 




Victoria Donnelly 
Registration No. 44,185 



Telephone: (613) 831-6003 
Facsimile: (613) 831-3329 
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